POC: MINIFICPP-985 - Implement listvalidators#618
POC: MINIFICPP-985 - Implement listvalidators#618arpadboda wants to merge 1 commit intoapache:masterfrom
Conversation
| class ListValidator : public PropertyValidator{ | ||
| public: | ||
| explicit ListValidator(T val) | ||
| : PropertyValidator("LIST_VALIDATOR"), |
There was a problem hiding this comment.
The name should somehow contain the underlying validator's name to work properly with C2.
This should be adjusted to the way Java MiNiFi or NiFi works.
That's why I made getName() virtual.
There was a problem hiding this comment.
The name pattern of non-list validators in nifi seem to be _VALIDATOR, and the pattern of list validators seem to be _LIST_VALIDATOR. [1]
I suggest cutting the _VALIDATOR suffix from the inner validator, replace it with _LIST_VALIDATOR suffix and pass that to the base class ctor. I'd also avoid making getName() virtual, since all the derived classes can already specify their desired names through the base class ctor parameter, so making it virtual would be a second customization point for the very same thing.
std::string replace_last(std::string str, const std::string& search, const std::string& replacement) {
str.replace(str.find_last_of(search), search.size(), replacement);
return str;
}
template<typename T>
ListValidator<T>::ListValidator(T inner_validator)
:PropertyValidator{ replace_last(inner_validator.getName(), "_VALIDATOR", "_LIST_VALIDATOR") },
[...]
| class ListValidator : public PropertyValidator{ | ||
| public: | ||
| explicit ListValidator(T val) | ||
| : PropertyValidator("LIST_VALIDATOR"), |
There was a problem hiding this comment.
The name pattern of non-list validators in nifi seem to be _VALIDATOR, and the pattern of list validators seem to be _LIST_VALIDATOR. [1]
I suggest cutting the _VALIDATOR suffix from the inner validator, replace it with _LIST_VALIDATOR suffix and pass that to the base class ctor. I'd also avoid making getName() virtual, since all the derived classes can already specify their desired names through the base class ctor parameter, so making it virtual would be a second customization point for the very same thing.
std::string replace_last(std::string str, const std::string& search, const std::string& replacement) {
str.replace(str.find_last_of(search), search.size(), replacement);
return str;
}
template<typename T>
ListValidator<T>::ListValidator(T inner_validator)
:PropertyValidator{ replace_last(inner_validator.getName(), "_VALIDATOR", "_LIST_VALIDATOR") },
[...]
| class MultiChoiceValidator : PropertyValidator { | ||
| public: | ||
| explicit MultiChoiceValidator (const std::set<std::string>& choices) | ||
| : PropertyValidator("LIST_VALIDATOR"), |
There was a problem hiding this comment.
Is it OK for MultiChoiceValidator to have the same name as ListValidator<T>? I couldn't find validator names referenced in minifi-c2, so I don't know whether this causes problems with C2.
|
Closing this because of inactivity. |
|
Reopening to bring back the topic - seems we will need this more and more |
2 participants
Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
Has your PR been rebased against the latest commit within the target branch (typically master)?
Is your initial contribution a single, squashed commit?
For code changes:
For documentation related changes:
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.